Amazon Aurora Serverlessをv1からv2にアップグレードしてみた(2024年8月更新)

Amazon Aurora Serverlessをv1からv2にアップグレードしてみた(2024年8月更新)

Clock Icon2022.05.09

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

移行手順を2024年8月時点の最新情報で更新しています

Amazon Aurora Serverlessはキャパシティ管理が不要なAmazon Auroraです。

v1v2の2種類が存在し、v1は2018年10月に、v2は2022年4月にGAになりました。

今回は、Amazon Aurora Serverless v1をv2に移行する方法を紹介します。

Amazon Aurora Serverless の違い

機能差

Amazon Aurora Serverlessはバージョンが一つ違うだけで、データベースエンジンのメジャーアップグレードとは比較にならないほど大きな変更が入っており、実質的に、全く別のサービスです。機能差は次のページにまとまっています。

Comparison of Aurora Serverless v2 and Aurora Serverless v1

例えば、以下の様な点には注意が必要です。

  • v2ではキャパシティを0にできない。
    • EventBridge Scheduler等で夜間になったら落とす
  • v2のData APIはPostgreSQLしか存在せず、MySQL向けは未対応
    • 踏み台経由でSQL操作する

Amazon Aurora Serverless の利用費

v1/v2ともにAurora Capacity Unit (ACU)を元に利用費が決定します。

ユニットの単価はv2のほうが高く、また、ユニットの粒度はv2のほうが細かいです。

料金 - Amazon Aurora | AWS

Aurora Capacity Unit (ACU)とServerlessの違い

Amazon Aurora Serverlessのv1と2はクラスターDBインスタンスの管理が全く異なります。

ProvisionedServerlessをキーワードに、違いを確認します。

クラスターの違い

Auroraクラスターは ServerlessとProvisionedの2種類があります。

従来型のクラスター、つまり、クラスター内のDBインスタンスをユーザーが作成するのが、Provisionedクラスターです。 一方で、Aurora Serverless v1のように、ユーザーはクラスターの単位で作成し、クラスター内のDBインスタンスには直接介入しないのが、Serverlessクラスターです。

Aurora Serverless v2はProvisioned型クラスターの一機能です。

DBインスタンスの違い

DBインスタンスにも ServerlessとProvisionedの2種類があります。

db.r6g.xlarge のような特定サイズのDBインスタンスを作成するのがProvisioned DBインスタンスです。 一方で、Aurora Serverless v2(=db.serverless)のように、インスタンス単位で動的にキャパシティがオートスケールするのが Sererless DBインスタンスです。

Provisionedクラスターには、ProvisionedとServerlessの両方のDBインスタンスを追加できます。

移行のポイント

  • Serverless v1からServerless v2に直接移行できない
    • Serverless v1のスナップショットから新しいProvisionedクラスターを作成する
    • スナップショットの取得から新クラスターが立ち上がるまでは更新作業を行えない
    • 切り替えが完了するまで、旧環境で参照処理を行うことは可能
    • 結果的に、移行元データベースは手つかずのまま残るので、切り戻しが簡単
  • MySQL/PostgreSQLどちらにしても、DBエンジンのメジャーアップグレードを伴う
    • メンテナンス中に一気に更新するならインプレースアップグレードするのがシンプル
    • 何が何でもダウンタイムを短くしたいなら、新しいProvisionedクラスターの構築完了を持って更新リクエストを受付、Blue/Greenで(数分のダウンタイムを許容して)メジャーアップグレード

やってみた

Aurora Serverless v1 MySQL 5.7を Aurora Serverless v2 に移行してみます。

移行の流れ

Aurora Serverless v1クラスターのスナップショットからAurora Provisionedクラスターを作成し、このProvisionedクラスターをServerless v2化します。

2つのクラスター間でリクエストの向き先を切り替えるまで、旧クラスターで参照系リクエストを受け付けることは可能です。また、新しいクラスターが立ち上がって切り替えが完了するまでは更新系リクエストを受け付けられません。

以下では、まとまったメンテナンス時間が確保できる前提で、直線的にServerless v2化までをシーケンシャルに実施します。

Aurora Serverless v1 PostgreSQL の場合は、適宜読み替えてください。

Aurora Serverless v1の作成

まず、移行元のAurora MySQL Serverless v1を作成します。

$ aws rds create-db-cluster \
  --db-cluster-identifier asv1-mysql \
  --engine aurora-mysql \
  --engine-version 5.7.mysql_aurora.2.11.3 \
  --engine-mode serverless \
  --scaling-configuration MinCapacity=1,MaxCapacity=2,SecondsUntilAutoPause=1000,AutoPause=true \
  --master-username username \
--master-user-password asdfqwer1234

Aurora Serverless v1のスナップショットを取得

Auroraクラスターをv1のServerless型からv2のProvisioned型に作り直すため、スナップショットを取得します。

Provisionedクラスターの起動

このスナップショットから Serverless v1と同じMySQLメジャーバージョン(5.7)の最新のAuroraのProvisioned Clusterを作成します。

コンソール操作では、メジャーバージョンの異なるAurora 3(MySQL 8.0互換)系も含まれていますが、いざ構築しようとすると、以下のようなエラーが発生します。

The engine version you requested for your restored DB cluster (8.0.mysql_aurora.3.05.2) is not compatible with the engine version of the DB cluster snapshot (5.7.mysql_aurora.2.11.4).

データベースエンジンのメジャーバージョン(今回だとMySQL 5.7)を揃えて移行してください。また、Auroraバージョンごとに対応しているDBインスタンスが異なります。$ aws rds describe-orderable-db-instance-options で確認してください。

$ aws rds describe-orderable-db-instance-options \
  --engine aurora-mysql \
  --engine-version 5.7.mysql_aurora.2.12.3 \
  --query 'OrderableDBInstanceOptions[].[DBInstanceClass,StorageType,Engine,EngineVersion]' \
  --output table

--------------------------------------------------------------------------
|                   DescribeOrderableDBInstanceOptions                   |
+------------------+---------+---------------+---------------------------+
|  db.r4.16xlarge  |  aurora |  aurora-mysql |  5.7.mysql_aurora.2.12.3  |
|  db.r4.2xlarge   |  aurora |  aurora-mysql |  5.7.mysql_aurora.2.12.3  |
|  db.r4.4xlarge   |  aurora |  aurora-mysql |  5.7.mysql_aurora.2.12.3  |
|  db.r4.8xlarge   |  aurora |  aurora-mysql |  5.7.mysql_aurora.2.12.3  |
|  db.r4.large     |  aurora |  aurora-mysql |  5.7.mysql_aurora.2.12.3  |
|  db.r4.xlarge    |  aurora |  aurora-mysql |  5.7.mysql_aurora.2.12.3  |
|  db.r5.12xlarge  |  aurora |  aurora-mysql |  5.7.mysql_aurora.2.12.3  |
|  db.r5.16xlarge  |  aurora |  aurora-mysql |  5.7.mysql_aurora.2.12.3  |
|  db.r5.24xlarge  |  aurora |  aurora-mysql |  5.7.mysql_aurora.2.12.3  |
|  db.r5.2xlarge   |  aurora |  aurora-mysql |  5.7.mysql_aurora.2.12.3  |
|  db.r5.4xlarge   |  aurora |  aurora-mysql |  5.7.mysql_aurora.2.12.3  |
|  db.r5.8xlarge   |  aurora |  aurora-mysql |  5.7.mysql_aurora.2.12.3  |
|  db.r5.large     |  aurora |  aurora-mysql |  5.7.mysql_aurora.2.12.3  |
|  db.r5.xlarge    |  aurora |  aurora-mysql |  5.7.mysql_aurora.2.12.3  |
|  db.r6g.12xlarge |  aurora |  aurora-mysql |  5.7.mysql_aurora.2.12.3  |
|  db.r6g.16xlarge |  aurora |  aurora-mysql |  5.7.mysql_aurora.2.12.3  |
|  db.r6g.2xlarge  |  aurora |  aurora-mysql |  5.7.mysql_aurora.2.12.3  |
|  db.r6g.4xlarge  |  aurora |  aurora-mysql |  5.7.mysql_aurora.2.12.3  |
|  db.r6g.8xlarge  |  aurora |  aurora-mysql |  5.7.mysql_aurora.2.12.3  |
|  db.r6g.large    |  aurora |  aurora-mysql |  5.7.mysql_aurora.2.12.3  |
|  db.r6g.xlarge   |  aurora |  aurora-mysql |  5.7.mysql_aurora.2.12.3  |
|  db.r6i.12xlarge |  aurora |  aurora-mysql |  5.7.mysql_aurora.2.12.3  |
|  db.r6i.16xlarge |  aurora |  aurora-mysql |  5.7.mysql_aurora.2.12.3  |
|  db.r6i.24xlarge |  aurora |  aurora-mysql |  5.7.mysql_aurora.2.12.3  |
|  db.r6i.2xlarge  |  aurora |  aurora-mysql |  5.7.mysql_aurora.2.12.3  |
|  db.r6i.32xlarge |  aurora |  aurora-mysql |  5.7.mysql_aurora.2.12.3  |
|  db.r6i.4xlarge  |  aurora |  aurora-mysql |  5.7.mysql_aurora.2.12.3  |
|  db.r6i.8xlarge  |  aurora |  aurora-mysql |  5.7.mysql_aurora.2.12.3  |
|  db.r6i.large    |  aurora |  aurora-mysql |  5.7.mysql_aurora.2.12.3  |
|  db.r6i.xlarge   |  aurora |  aurora-mysql |  5.7.mysql_aurora.2.12.3  |
|  db.t2.medium    |  aurora |  aurora-mysql |  5.7.mysql_aurora.2.12.3  |
|  db.t2.small     |  aurora |  aurora-mysql |  5.7.mysql_aurora.2.12.3  |
|  db.t3.large     |  aurora |  aurora-mysql |  5.7.mysql_aurora.2.12.3  |
|  db.t3.medium    |  aurora |  aurora-mysql |  5.7.mysql_aurora.2.12.3  |
|  db.t3.small     |  aurora |  aurora-mysql |  5.7.mysql_aurora.2.12.3  |
|  db.t4g.large    |  aurora |  aurora-mysql |  5.7.mysql_aurora.2.12.3  |
|  db.t4g.medium   |  aurora |  aurora-mysql |  5.7.mysql_aurora.2.12.3  |
+------------------+---------+---------------+---------------------------+

Aurora 2(MySQL 5.7)からAurora 3(MySQL 8.0)へのメジャーアップグレード

Aurora 2(MySQL 5.7互換)からAurora3(MySQL 8.0互換)へのメジャーアップグレードには、Blue/Greenデプロイメントまたはインプレースアップグレードがあります。

方法 手順 ダウンタイム エンドポイント 切り戻し先
Blue/Green 普通 瞬断 同じ 残る
インプレース シンプル 長い 同じ スナップショットからリストア

今回は、移行元のAurora Serverless v1が手つかずのまま残っており、Aurora Serverless v1のスナップショットを取得してからは書き込みのできない状態であることを考慮すると、シンプルにインプレースアップグレードの採用が素直です。

少しでもダウンタイムを縮めたい場合は、新しいAurora 2(MySQL 5.7)クラスターが立ち上がったタイミングで更新処理を受け付け、Blue/GreenでAurora 3(MysQL 8.0)にメジャーアップグレードすることもできます。ただし、手順が複雑になり、切り戻しも含め、いろいろなシナリオを考慮する必要があります。

AWSは本番環境ではblue/greenを推奨しています。

You can convert your Aurora Serverless v1 DB cluster to a provisioned DB cluster, then use a blue/green deployment to upgrade it and convert it to an Aurora Serverless v2 DB cluster. We recommend this procedure for production environments.
https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-serverless-v2.upgrade.html

Aurora 3のProvisionedインスタンスをServerless v2に変更

ProvisionedクラスターのDBインスタンスはProvisioned型とServerless型を混在したり、インスタンスをProvisioned型とServerless型で行き来させることができます。

クラスター作成後、Provisioned型で作成したDBインスタンスのクラスをServerless v2に変更します。

以上で、Serverless v1からv2への移行が完了しました。

最後に

Amazon Aurora Serverlessをv1からv2への移行ポイントは以下です。

  • v1はクラスターがServerless。v2はクラスターがProvisioned、DBインスタンスがServerless
  • ProvisionedクラスターのDBインスタンスはProvisioned型とServerless型で切り替え可能
  • Aurora Serverless v1からv2への直接移行パスは存在しない
  • スナップショットを経由して、新しいProvisionedクラスターの作成とDBエンジンのメジャーバージョンを伴う
  • 更新処理を再開するタイミングは選択肢が2つ
    • ダウンタイムを長く取れる場合は、インプレースでメジャーアップグレード&Serverless v2した後で再開すると、切り戻しも含めて手順がシンプルになる
    • ダウンタイムを少しでも短くしたい場合は、新しいProvisionedクラスターの作成後に更新リクエストを再開し、Blue/Greenでメジャーアップグレード&Serverlss v2を行う。この場合、分岐が多く複雑になる。AWSの本番環境の推奨手順はBlue/Green

それでは。

参考

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.